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Integrating  Multiple  Sources  of  Knowledge 
into  Designer-Soar, 
an  Automatic  Algorithm  Designer1 

David  Staler  and  Allan  Newell 

Department  of  Computer  Science 
Carnegie  Mellon  University 
Pittsburgh.  PA  15213-3890 


Abstract 

Designing  algorithms  requires  diverse  knowledge  about  general 
problem-solving,  algorithm  design,  implementation  techniques,  and 
the  application  domain.  The  knowledge  can  come  from  a  variety  of 
sources,  including  previous  design  experience,  and  the  ability  to 
integrate  knowledge  from  such  diverse  sources  appears  critical  to 
the  success  of  human  algorithm  designers.  Such  integration  is 
feasible  in  an  automatic  design  system,  especially  when  supported 
by  the  general  problem-solving  and  learning  mechanisms  in  the  So* 
architecture.  Our  system.  Designer-Soar,  now  designs  several 
simple  generate-and- test  and  divide-and -conquer  algorithms.  The 
system  already  uses  several  levels  of  abstraction,  generalizes  from 
examples,  and  learns  from  experience,  transferring  knowledge  ac¬ 
quired  during  the  design  of  one  algorithm  to  aid  in  the  design  of 
others. 

1.  Introduction 

The  frontier  of  artificial  intelligence  research  has  recently  been 
described  as  "figuring  out  how  to  bring  more  kinds  of  knowledge  to 
bear  [18]".  This  paper  addresses  the  question  of  how  to  bring  more 
kinds  of  knowledge  to  bear  in  an  automatic  algorithm  design  system. 
A  designer  should  be  able  to  use  knowledge  about  general  problem¬ 
solving,  algorithm  design,  implementation  techniques,  the  applica¬ 
tion  domain  and  prior  experience.  We  describe  a  system,  Designer- 
Soar,  that  both  applies  knowledge  from  these  different  sources  and 
acquires  knowledge  for  transfer  to  future  problems.  We  adapt  and 
extend  techniques  used  in  Designer  [9],  an  initial  implementation  of 
an  algorithm  design  system,  and  exploit  the  special  properties  of  the 
Soar  architecture  [13]. 

The  focus  of  this  research  is  on  the  design  o,  'sc--  hint,  rather 
than  their  implementation.  We  define  algorithm  n  to  be  the 
process  of  sketching  a  computationally  feasible  technique  for  ac¬ 
complishing  a  specified  behavior  [9].  Given  such  a  sketch,  a 
programmer  may  then  proceed  to  an  efficient  implementation  of  the 
algorithm.  Although  we  focus  on  the  eariy  design  stages  of  the  total 
programming  process,  we  expect  similar  issues  of  multiple 
knowledge  sources  to  arise  in  later  stages  as  well. 


'Thix  mwrii  ni  spawned  by  the  Detente  Advanced  Retetidt  Projects  Agency 
(DOD).  ARPA  Order  No.  4976  under  coitnct  03615-87.01499,  and  momused  by 
the  Air  Force  Avionici  Laboratory.  The  research  was  also  supported  in  part  under  a 
Schluanberger  Graduate  Fellotnhip  to  David  Stater  The  vtewc  and  catdiuaonc 
contained  in  this  document  are  those  of  the  authors  and  thauld  not  be  interpreted  as 
representing  the  ofBasl  policies,  either  expressed  or  implied,  of  the  Detenu  Advanced 
Research  Projects  Agency,  Schlienberge,  or  the  U.S.  Govenencm. 


2.  The  Need  for  Knowledge  Integration  in  Algorithm 
Design 

By  knowledge  we  mean  the  information  about  some  domain, 
abstracted  from  the  representation  used  to  encode  it  and  the  process¬ 
ing  required  to  make  it  available  [20].  A  knowledge  source  is  a 
system  that  provides  access  to  a  body  of  knowledge.  A  knowledge 
source  has  a  specific  representation  of  the  knowledge,  comprising 
both  symbolic  structures  and  the  means  for  interpreting  them  to 
influence  actions,  when  appropriate.  The  problem  of  integration  of 
multiple  sources  of  knowledge  arises  from  the  diversity  of  represen¬ 
tations  of  the  sources,  each  of  which  may  differ  from  the  represen¬ 
tation  used  to  select  actions  to  attain  the  goals  of  the  system.  It  is 
always  much  easier  to  design  a  system  with  a  single  source  of 
knowledge,  where  the  representation  for  action  selection  can  be 
directly  adapted  to  it. 

The  kinds  of  knowledge  relevant  to  algorithm  design  are 
described  below.  Table  1  gives  typical  processes  in  design  systems 
that  apply  this  knowledge. 

Kl.  Weak  methods:  Designing  algorithms  requires  solving 
problems.  Human  problem  solvere  (but  generally  not  automatic 
systems)  usually  manage  to  make  some  progress,  even  if  they  don't 
have  all  (he  knowledge  necessary  in  the  form  of  powerful  domain 
specific  techniques.  They  resort  to  weak  methods,  such  as  generat¬ 
ing  and  testing  many  solutions,  depth-first  search,  etc.  Human 
algorithm  designers  show  particularly  heavy  use  of  means-ends 
analysis  [11].  They  work  to  reduce  the  differences  between  the 
current  state  and  the  goal  state,  resulting  in  problem  solving  driven 
by  difficulties  and  opportunities  detected. 

K2.  High-level  algorithm  schemes:  Algorithm  designers  usually 
begin  to  attack  a  problem  using  design  schemes.  A  common  ex¬ 
ample  is  divide-and-conquer.  splitting  a  problem  into  subproblems, 
solving  the  subproblems  separately,  and  merging  the  solutions  to 
solve  the  original  problem  [24], 

K3.  Transformations:  Once  some  procedural  representation  of 
the  algorithm  exists,  other  knowledge  suggests  ways  to  reformulate 
and  refine  the  procedure  into  a  better  solution.  One  generally 
applicable  transformation  is  recursion  formation  as  used  in  [15]. 
Transformations  more  specific  to  particular  situations  have  been 
collected  in  libraries  of  rules  [3]  or  programming  overlays  that  show 
correspondences  between  plans  [21]. 

K4.  Correctness:  Knowledge  suggesting  transformations  to  apply 
is  complemented  by  other  knowledge  asserting  the  application  of  a 
transformation  will  satisfy  some  design  goals.  Particularly  in 
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derivation  systems  developed  by  the  program  transformation  com¬ 
munity,  transformations  are  known  to  preserve  desired  semantic 
properties  in  program  descriptions.  But  sometimes  there  is  no 
knowledge  that  any  known  transformations  preserve  the  desired 
property.  One  way  to  acquire  this  knowledge  is  to  prove  the  trans¬ 
formation  correct;  another  is  to  apply  a  transformation  and  test  the 
results  by  executing  the  resulting  design  [26], 

K5.  Efficiency:  Knowledge  about  efficiency  may  take  several 
forms.  It  is  useful  to  know  that  extra  effort  devoted  to  finding  a 
divide-and-conquer  algorithm  may  ultimately  yield  a  more  efficient 
algorithm  than  a  generate- and  test  scheme  [9].  The  balancing 
principle,  which  applies  specifically  to  divide-and-conquer  al¬ 
gorithms,  state  that  the  optimal  divide  step  produces  subproblems  of 
equal  size. 

K&  Target  language  and  architecture:  Knowledge  about  the 
intended  target  language  and  architecture  is  mainly  important  in  the 
later  (coding)  stages  of  program  synthesis  [3,  4],  However,  the 
availability  of  certain  language  features  (e.g„  bit  operations)  may 
influence  the  choice  of  algorithm  used;  architectural  features  (e.g., 
parallelism)  may  create  opportunities  for  using  algorithms  that 
would  be  otherwise  impossible. 


Each  type  of  knowledge  has  been  incorporated  into  at  least  one 
system  for  automating  algorithm  design  or  other  phases  of  program¬ 
ming.  Table  2  indicates  the  degree  to  which  such  systems 
(including  Designer-Soar)  integrate  multiple  sources  of  knowledge. 
The  top  half  of  the  table  lists  systems  that  emphasize  algorithm 
design:  Designer-Soar,  Designer  [10],  Cypress  [24],  Cypress-Soar2 
[23],  MEDUSA  [16],  and  STRATA  [14],  The  second  half  of  the 
table  lists  systems  that  emphasize  other  pans  of  programming: 
DEDALUS  [13],  PSI/SYN  [12],  Glitter  [7],  [4],  KBEMACS 

[28]  and  DRACO  [19]. 

The  table  shows  that  no  single  system  integrates  all  the  sources  of 
knowledge.  Weak  methods,  domain  procedures,  and  learned 
knowledge  are  used  most  infrequently.  As  expected,  the  systems 
that  emphasize  algorithm  design  use  less  knowledge  of  the  target 
language  and  architecture  than  the  other  systems.  Also,  those  sys¬ 
tems  most  strongly  driven  to  handle  difficult  real-world  problems 
are  the  ones  that  incorporate  (or  plan  to  incorporate)  the  most  types 
of  knowledge.  This  is  particularly  true  of  which  is  intended 
to  produce  usable  oil  well  logging  software,  and  DRACO,  which  has 
been  used  for  the  analysis  of  domains  such  as  real-time  tactical 
display  systems. 


K7.  Domain  definitions:  As  with  programming  in  general  [4], 
algorithm  specification  and  design  require  domain  knowledge.  For 
example,  in  specifying  a  sorting  algorithm,  Clark  and  Darlington  use 
logical  axioms  and  lemmas  to  give  the  semantics  of  the  terms 
ordered  and  permutation  [5].  Other  types  of  domain  knowledge 
provide  performance  constraints,  input  data  characteristics,  etc. 

K8.  Domain  procedures:  Human  designers  invariably  under¬ 
stand  the  algorithm  specifications  proceduraily.  No  one  designs  a 
sorting  algorithm  who  does  not  know  how  to  sort  Novice  LISP 
programmers  often  solve  sample  problems  by  hand,  and  then  map 
the  structure  of  their  hand  solution  onto  LISP  [1].  Using  examples 
provides  a  focus  of  attention  for  reasoning,  excluding  irrelevant 
attributes  and  unrealistic  situations  that  might  result  from  exclusive 
use  of  an  abstract  domain  theory  [17], 

K9.  Learned  knowledge  (K1  -  K8):  Human  designers  leam  from 
experience,  acquiring  knowledge  ranging  from  specific  sub¬ 
procedures  to  general  design  techniques.  The  importance  of  reuse 
for  automation  of  programming  is  commonly  recognized 
(Z  6. 7,  19],  but  we  are  only  beginning  to  understand  how 
automatic  programming  systems  can  learn  [8,  23]. 


3.  The  Task  of  Algorithm  Design  in  Designer-Soar 

The  problem-solving  architecture  is  critical  to  a  system  that  per¬ 
mits  integrating  multiple,  diverse  knowledge  sources.  The  Soar 
architecture  [13]  appears  to  have  the  requisite  generality.  Soar  sys¬ 
tems  have  solved  problems  and  learned  in  domains  ranging  from  the 
traditional  AI  toy  problems  such  as  the  eight-puzzle  to  more  com¬ 
plex  knowledge-intensive  tasks,  such  as  pan  of  the  VAX  configura¬ 
tion  performed  by  the  R1  expert  system  [22].  Soar  also  provides  a 
way  to  explore  transfer  of  learned  knowledge  both  within  a  design 
and  between  designs. 

Soar  represents  tasks  as  search  in  problem  spaces:  sets  of  states, 
with  operators  that  move  from  state  to  state,  and  the  free  ability  to 
search  within  the  space  for  a  desired  state  that  represents  task 
accomplishment.  Knowledge  is  embodied  in  productions,  which  arc 
used  to  select  problem  spaces,  stales,  and  operators.  Productions 
also  implement  simple  operators,  complex  operators  being  treated  as 
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algorithm*,  while  Designer-Sou  design*  these  *nd  other  tlgonthms  without  such  * 
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tasks,  which  are  accomplished  in  appropriate  problem  spaces.  With 
insufficient  or  conflicting  knowledge.  Soar  reaches  an  impasse  and 
generates  a  subgoal  to  resolve  it.  When  subgoals  are  terminated. 
Soar  learns  from  the  experience  by  building  new  productions, 
chunks.  The  left-hand  side  of  a  chunk  consists  of  generalized 
conditions  on  the  working  memory  elements  used  in  producing  the 
results  of  the  subgoaL  If  these  conditions  become  true  again,  the 
chunk  will  fire  to  automatically  apply  the  knowledge  &om  the 
previous  solution,  and  avoid  the  subgoaL  Transfer  of  knowledge 
oocun  because  the  chunk's  conditions  abstract  away  from  inessen¬ 
tial  features  of  the  original  situation. 

Design  tasks  are  given  to  Designer-Soar  in  terms  of  two  sets  of 
problem  spaces.  One  defines  the  computational  model;  its  operators 
are  the  primitives  in  which  to  express  the  algorithm.  The  other 
defines  the  application  domain  of  the  algorithm.  The  desired  be¬ 
havior  of  the  algorithm  can  be  operationally  specified  by  the  system 
knowing  how  to  perform  the  task  in  the  domain.  Thus,  Designer- 
Soar  understands  sotting  if  it  can  son  sequences  in  the  domain 
space.  The  algorithm  design  task  is  to  express  sorting  in  the  com¬ 
putational  model,  which  (for  algorithm  design,  as  opposed  to  pro¬ 
gramming  in  a  specific  language)  is  a  space  that  has  abstract 
operators  that  correspond  to  the  capabilities  of  computers.  The  total 
specification  of  the  design  task  may  require  additional  subspaces  to 
define  the  operators  and  additional  operational  knowledge  about 
how  to  work  within  the  two  main  spaces.  Additional  constraints 
may  come  from  performance  requirements  on  the  algorithm  or  from 
resource  limitations  on  the  design  process  itself. 

This  definidon  of  the  task  of  algorithm  design  separates  the  un¬ 
derstanding  of  what  the  algorithm  is  to  do  from  the  creation  of  an 
algorithm  within  some  computational  framework.  If  Designer-Soar 
does  not  know  how  to  sort  at  ail,  then  it  must  first  acquire  that 
understanding,  which  will  occur  as  a  capability  within  the  domain 
space  for  sorting,  namely,  a  space  of  absoact  sequences.  Designer- 


Soar  designs  the  algorithm  by  working  in  the  computational  space 
until  it  can  perform  the  task  (e.g.,  sorting)  in  a  functionally  equiv¬ 
alent  way  to  the  domain-space  algorithm,  while  satisfying  the  given 
constraints.  The  chunks  that  are  teamed  for  the  target  computational 
spaces  implement  an  algorithm. 

4.  Knowledge  Integration  in  Designer-Soar 

We  will  discuss  knowledge  integration  in  Designer -Sow  by  the 
example  of  designing  insertion  son.  which  Designer-Soar  syn¬ 
thesizes  in  the  same  form  is  that  created  by  Cypress  [23]  and 
Cyjxess-Soar  (25].  The  algorithm  is  two  di  v  ide-  and -conquer  al¬ 
gorithms,  one  for  the  top  level  sort  function  and  one  for  inserting  an 
element  into  an  ordered  sequence  (the  composidon  subprocedure). 
Sort  takes  a  sequence  of  elements  to  be  sorted  as  input  If  the 
sequence  is  empty,  it  is  returned  directly  as  already  sorted;  otherwise 
the  sequence  is  split  into  its  first  element  and  the  rest  of  the  se¬ 
quence.  The  first  element  is  then  inserted  into  the  result  of  recur¬ 
sively  sorting  the  remainder  of  the  sequence.  Insert  takes  an  ele¬ 
ment  and  an  ordered  sequence  as  input.  If  the  sequence  is  empty, 
the  function  returns  a  sequence  containing  only  the  element;  other¬ 
wise,  a  conditional  subprogram  is  called  to  decompose  the  input  into 
smaller  subproblems.  The  subprogram  compares  the  value  of  the 
element  parameter  to  the  value  of  first  element  of  the  sequence 
parameter.  If  we  assume  Xq  corresponds  to  the  smaller  element,  x, 
to  the  larger  element,  and  Xj  to  the  remainder  of  the  sequence,  the 
condidonal  returns  a  pair  of  the  form  <x0><x,jc2».  The  fust 
parameter  is  then  prepended  to  the  result  of  recursively  calling  the 
insertion  function  on  the  second  parameter  (the  nested  pair). 

The  target  computational  model  space  has  dataflow  operators  that 
correspond  to  the  conceptual  building  blocks  for  algorithms,  such  as 
test  a  data  item  for  some  predicate,  and  apply  some  function  to 
data  [11].  Algorithm  schemes  can  be  encoded  procedural ly  as 
higher-level  operators  that  are  implemented  in  terms  of  these  build- 
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ing  blocks.  For  example,  Designer-Soar  has  compose  and 
decompose  operators  that  correspond  to  decomposing  problems 
into  subproblems,  and  composing  subproblems  solutions  to  get  the 
answer  to  the  original  problem..  These  are  not  implemented  directly 
by  productions.  When  attempting  to  apply  these  operators  in  ex¬ 
ecuting  an  algorithm,  an  impasse  results,  with  a  corresponding  sub¬ 
goal  to  acquire  the  knowledge  to  implement  them.  Designer-Soar 
knows  an  algorithm  when  it  can  select  and  implement  the  ap¬ 
propriate  dataflow  operators  to  compute  the  correct  output  given  any 
legal  input.  This  uniform  procedural  representation  of  abstractions 
at  levels  varying  from  algorithm  schemes  down  to  computational 
primitives  is  crucial  to  knowledge  integration  in  Designer-Soar. 

The  design  of  insertion  sort  is  summarized  in  Table  3.  Column  1 
labels  the  design  choice  and  gives  the  decision  cycle  at  which  the 
choice  occur ed.  The  decision  cycle  is  the  basic  unit  of  problem 
solving  effort  in  Soar  (the  entire  run  takes  383  decision  cycles, 
requiring  about  35  minutes  on  a  Sun3/260).  Column  2  summarizes 
the  design  choices;  column  3  gives  Designer-Soar's  reasons  for 
making  the  choice.  Column  4  lists  the  types  of  knowledge  used  for 
each  choice.  We  describe  the  design  process  in  more  detail  in  the 
following  subsections. 

4.1.  Acquiring  the  specification  and  a  plan  (Cl  •  C2) 

The  goal  of  algorithm  design  is  to  be  able  to  know  what  to  do  to 
execute  the  algorithm  on  any  valid  input.  Designer-Soar  makes 
design  choices  while  repeatedly  executing  both  the  domain  prece¬ 


des!  gn  in  Designer-Soar 

dure  and  the  partially  designed  algorithm  at  varying  levels  of 
abstraction.  The  results  of  the  executions  are  used  to  detect 
problems  and  opportunities  that  guide  the  design,  so  that  the  design 
process  can  be  characterized  more  as  means-ends- analysis  than  as 
strict  top-down  refinement 

Designer-Soar  first  attempts  to  execute  the  insertion-sort  algo¬ 
rithm  (which  doesn’t  exist  yet)  to  see  what  needs  to  be  done.  .An 
impasse  is  generated  because  Designer-Soar  has  not  yet  learned  how 
to  select  between  the  computational  operators  it  could  apply  as  a 
first  step.  While  resolving  this  impasse,  Designer-Soar  learns  that 
the  algorithm  should  have  the  functionality  of  the  high-level  domain 
operator  "sort  a  sequence  into  nondecreasing  order."  Designer- 
Soar  already  has  the  knowledge  to  implement  sort  m  domain 
spaces,  but  acquires  the  knowledge  to  select  the  sort  operator  for 
this  run  by  translating  an  external  task  description  mto  an  internal 
description  of  the  operator  selection  knowledge,  and  then  inter¬ 
preting  this  description  to  build  a  procedural  representation  of  tie 
knowledge  as  an  operator  selection  chunk  [29]. 

Knowledge  that  the  algorithm  must  sort  is  used  to  select  an 
operator  to  apply  in  the  computational  space.  The  operator  selected 
implements  the  first  step  of  divide-and-conquer:  a  test  to  check  if  tie 
input  is  decomposable.  The  operator  is  selected  according  o  tie 
results  of  a  subgoal  to  evaluate  the  choice  by  lookahead,  i.e..  .tying 
out  the  operator  to  see  if  it  leads  to  a  final  slate.  The  exact  test  for 
decomposability  is  not  yet  known,  and  no  concrete  example  lias 


been  produced  to  refine  il  Therefore,  the  lookahead  takes  place  in 
an  abstracted  version  of  the  computational  space,  in  which  the 
operators  can  be  allied  without  knowing  the  missing  details3.  Cur¬ 
rently,  Designer-Soar  only  uses  type  knowledge  in  abstracted  execu¬ 
tion,  but  we  expect  to  propagate  efficiency  constraints  as  well. 

4.2.  Designing  the  top  levei  sort  (C3  -  C6) 

Given  the  decision  to  execute  a  divide -and-conquex  algorithm, 
Designer-Soar  attempts  to  apply  the  first  step,  testing  for  decom- 
pos ability.  The  test  is  not  known,  but  the  system  knows  that  execu¬ 
tion  on  concrete  examples  is  useful  for  refining  tests,  so  a  new 
execution  pass  is  begun.  An  example  of  the  input  required,  a 
sequence  of  integers,  is  incrementally  generated  by  adding  elements 
to  an  initially  empty  sequence  until  it  has  two  elements.  Designer- 
Soar  knows  that  sequences  with  two  or  more  elements  will  probably 
not  be  boundary  cases  (in  contrast  to  zero  or  one  elements).  To  find 
the  test  for  decomposability,  Designer-Soar  looks  ahead  for  a  pos¬ 
sible  decomposition  operator.  We  have  told  the  system  to  select  the 
F  i  rstSest  operator  for  decomposition  in  this  case  (which  leads  to 
insertion  sort  rather  than  other  sorting  algorithms),  splitting  off  the 
first  element  from  the  sequence  containing  the  second  element.  The 
precondition  for  applying  FirstRest  —  that  the  sequence  has  at 
least  one  element  —  is  used  as  the  test  for  decomposability. 

The  subproblems  from  this  decomposition  are  then  solved.  The 
first  subproblem  is  an  element  rather  than  a  sort  able  sequence,  and  is 
passed  to  the  composition  as  is.  The  remaining  subproblem  is  a 
sequence,  and  test-case  execution  is  recursively  invoked  to  sort  it  It 
is  decomposed  into  an  element  and  an  empty  sequence.  The  test  for 
decomposability  applied  to  the  empty  sequence  returns  false,  so  it 
must  be  sorted  directly.  Applying  the  domain  operator  to  sort  the 
empty  sequence  shows  that  the  computational  space  operator  Id 
(identity)  operator  has  the  necessary  functionality. 

43.  Designing  the  insertion  algorithm  (C7  -  CIO) 

While  malting  these  selection  and  implementation  choices, 
Designer-Soar  learns  chunks.  Because  of  the  execution  paths  fol¬ 
lowed  so  far,  the  chunks  teamed  encode  the  entire  structure  of  the 
top  level  of  the  insertion  sorting  algorithm.  However,  an  impasse 
arises  when  the  system  tries  to  combine  the  element  and  die  sorted 
remaining  sequence,  because  it  does  not  know  how  to  implement  the 
necessary  Compose  operator.  It  decides  to  implement  the  operator 
by  divide-and-conquer,  making  the  selection  by  the  same  abstract 
lookahead  planning  used  for  the  higher  level  algorithm;  indeed  some 
of  the  chunks  learned  then  now  apply,  speeding  up  the  problem¬ 
solving.  showing  the  integration  of  learned  knowledge.  To  refine 
the  insertion  subalgorithm  further,  the  2-element  example  from  the 
higher-level  execution  context  is  used  again.  We  told  the  system  to 
assume  the  decomposition  for  insertion  would  have  to  be  custom 
designed  and  that  the  composition  would  be  selected  from  simple 
known  operators.  In  fact,  decompose  need  not  be  applied  for  the 
current  input,  which  is  an  element  and  an  empty  sequence.  The 
check  for  the  empty  sequence  is  made  into  a  test  for  decom¬ 
posability.  A  comparison  to  results  of  execution  in  domain  space 
shows  that  the  operator  Cons  suffices  to  insert  an  element  into  an 
empty  sequence. 


current  example,  it  knows  that  the  purpose  of  the  execution  is  not 
only  to  obtain  the  answer,  but  also  to  exercise  the  execution  paths  so 
that  it  learns  the  algorithm.  In  finding  that  the  test  for  decom¬ 
posability  returns  false,  it  remembers  it  must  come  back  to  find  out 
what  happens  when  a  test  returns  true.  It  generates  a  new  example 
to  force  the  execution  down  the  untried  path,  adding  an  element  to 
the  sequence  to  make  it  decomposable. 

In  processing  the  new  example  and  looking  at  ihe  results  of 
domain  execution,  the  system  discovers  that  it  needs  to  handle 
several  cases  separately  for  the  decomposition.  This  leads  to  a 
conditional  algorithm,  where  inputs  are  an  element  and  an  ordered 
sequence.  Another  execution  pass  refines  the  predicate  of  the  con¬ 
ditional  to  compare  the  value  of  the  element  to  the  value  of  the  first 
element  of  the  sequence,  and  also  refines  the  true  branch  to  ensure 
that  the  smaller  of  the  two  elements  is  moved  to  the  front.  Some  of 
the  knowledge  learned  in  refining  the  true  branch  is  used  together 
with  a  new  example  to  refine  the  false  branch  analogously.  While 
finishing  the  design,  the  composition  operation  of  the  insertion  is 
refined  to  Cons  the  element  (known  to  be  smallest)  to  the  front. 


4 £.  Learning 

Prior  experience  is  a  significant  source  of  knowl  -<ge  for  design. 
Soar's  learning  mechanism,  chunking,  is  so  tightly  integrated  into 
Designer-Soar  that  the  boundary  between  problem-solving  and 
learning  has  disappeared:  designing  an  algorithm  is  equivalent  to 
learning  to  execute  it  and  the  current  Designer-Soar  requires  that 
chunking  be  on  to  run.  However,  a  slightly  earlier  version  of 
Designer-Soar  did  permit  no -chunking  runs  so  as  to  isolate  the 
effects  of  learning.  Figure  4-1  shows  the  cumulative  problem¬ 
solving  effort  needed  to  design  two  simple  algorithms  in  sequence, 
with  and  without  chunking.  On  the  left,  the  first  algorithm  finds  the 
subset  of  elements  satisfying  a  given  predicate  in  a  given  set,  the 
second  finds  the  intersection  of  two  sets.  On  the  right,  the  two 
algorithms  are  insertion  sort  and  merge  sort.  There  is  a  significant 
savings  from  learning  in  both  pain  of  algorithms:  28%  for  the  set 
algorithms  and  69%  for  the  sorting  algorithms,  illustrating  that  the 
benefits  of  learning  increase  as  the  designs  get  more  complex.  Fur¬ 
thermore,  the  slope  of  the  learning  graph  decreases  during  the  design 
of  the  second  algorithm  in  each  pair,  suggesting  transfer  across,  as 
well  as  within,  the  similar  designs.  We  found  that  without  the 
chunks  from  the  design  of  insertion  sort,  the  learning  run  for  merge 
sort  takes  860  decision  cycles,  an  increase  of  56%  over  the  551 
needed  with  those  chunks. 


Figure  4-1:  Effects  of  learning  in  Designer-Soar 


4.4.  Designing  the  decomposition  of  the  insertion 
algorithm  (Cll  -  C15) 

Though  Designer-Soar  has  solved  the  problem  of  insertion  for  the 


3 A  siruIw  use  of  abstraction  m  Soar  has  been  described  for  a  psnui  reunplcmen- 
isuon  of  Rl.  the  VAX  configuration  expert  system  (271. 


5.  Summary 

Returning  to  our  list  of  knowledge  sources,  we  summarize  ihe 
mechanisms  used  for  integrating  each  source  into  Dcsigncr-Soor. 
The  Soar  architecture  directly  supports  access  and  use  of  two  of  ihe 
knowledge  sources:  weak  method  search  (Kl)  results  from  Soar's 
default  behavior  in  knowledge- lean  situations,  and  .earned 


knowledge  (K9)  is  applied  when  chunks  fire.  The  problem  spaces 
that  are  specific  to  Designer-Soar  support  integration  of  the  other 
sources.  Knowledge  of  the  high-level  algorithm  schemes  (K2)  and 
of  possible  transformations  (K3)  is  encoded  in  the  operators  in  the 
computational  spaces.  Similarly,  knowledge  about  application 
domain  definitions  and  procedures  (K7  and  K8)  is  embodied  in  the 
structure  of  the  domain  spaces.  Concerns  of  correctness  (K4)  are 
addressed  by  execution  in  both  computational  and  domain  spaces, 
and  means-ends  analysis  on  the  results.  Though  we  have  not  yet 
focused  on  knowledge  about  efficiency  (K5)  or  the  target  language 
and  architecture  (K6),  there  is  a  clear  role  for  integrating  these 
sources  in  terms  of  selection  knowledge  in  the  computational  space, 
or  even  computational  spaces  with  different  functional  operators. 

Currently,  Designer-Soar  designs  both  generate-and-test  and 
divide-and-conquer  algorithms,  but  only  simple  instances  of  each. 
We  are  now  reorganizing  Designer-Soar  to  give  it  greater  generality 
and  robustness.  Wo  expect  that  the  results  we  obtain  in  integration 
of  multiple  knowledge  sources,  including  learning,  will  have  im¬ 
plications  not  only  for  algoridun  design,  but  for  otheT  applications  as 
well. 
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